你有沒有遇過這種需求會議——大家一邊畫流程，一邊嘴上說：「如果是學生的話…」「欸，那如果是 25 人以上又不是學校呢？」「但那是假日欸…」

會議室的白板上很快寫滿了條件和例外狀況，但當你試著把它們變成具體範例時，卻突然卡住了。因為你發現：
• 條件太多，組合起來變成一個邏輯迷宮
• 你根本不知道目前提到的例子，覆蓋了哪些情境、又漏了哪些重要組合
• 大家提出的「範例」彼此矛盾，SBE workshop 變成一場口水戰

這其實不是你的錯。這是很多產品在邏輯密集領域中都會遇到的問題。而這種情況下，如果我們只是憑直覺產生範例（例如用三五個故事來代表整個規則），反而會讓 SBE 變成一種「以偏概全」的危險遊戲。

這時候，我們需要的，不是更多腦補故事，而是一個讓你系統性釐清所有條件組合與行為的工具。

這個工具，就是 Decision Table Testing（決策表測試, DTT）。

Decision Table Testing 原本是為了在複雜商業規則中，進行「邏輯完整性檢查」的測試方法。它的強項在於：
• 條件越多，它越能幫你完整交叉排列
• 當你懷疑需求有缺漏，它會直接「用空格說話」
• 它不是依賴人的記憶或理解，而是依據條件交錯的規律產生結果

而這正好能完美補上 Specification by Example 的一個常見弱點——
我們太容易沉浸在「這個故事對不對」的爭論，卻沒有人真正檢查：這些範例的邏輯範圍夠完整嗎？

換句話說：

Decision Table 是你產生 SBE 範例的「全貌地圖」，幫你確認「哪些你有說過」「哪些你沒說清楚」，讓每一個範例都有其邏輯位置，也讓每個空白成為回頭找 PO 問清楚的依據。

SBE 是用「範例」促進溝通，而 Decision Table 是幫你確保這些範例的「涵蓋面」與「組合邏輯」不會失真。

接下來，我們會說明什麼是 Decision Table Testing、它的優缺點、操作步驟，並透過實際案例，說明如何應用在 SBE 的範例設計中，甚至進一步讓團隊找出邏輯漏洞、釐清模糊地帶。

你會發現，有了 Decision Table，SBE 不再是靠靈感拼圖，而是一場有依據、有地圖的共識建立過程。

一、什麼是 Decision Table Testing？

Decision Table Testing（決策表測試）是一種將條件邏輯「攤開來看」的測試設計技術，用來系統化分析「在各種輸入條件組合下，系統應該如何行為」。

它特別適合處理以下這類需求狀況：

• 條件多、規則複雜
• 輸入條件之間會交互影響結果
• 有許多例外處理或替代流程
• 你懷疑需求中有邏輯漏洞或未定義的情況

Decision Table中由兩大核心構成：條件（Conditions）與行為（Actions）

(1) 條件（Conditions）：系統在做決策時會根據的輸入因素。

• 每個條件都代表一個「是／否」或分類型的檢查點，例如：
• 是否為學校團體？（是／否）
• 是否為指定車次？（是／否）
• 團體人數區間？（<11、11–24、≥25）

(2) 行為（Actions）：當這組條件成立時，系統應該執行的動作。
一組條件可能對應一個或多個行為，例如：

• 顯示折扣金額（如：4 折、7 折）
• 自動套用優惠名稱（如：校外教學優惠）
• 拋出錯誤訊息（如：未搭乘指定車次，優惠無效）
• 發送通知給管理者（內部流程）

二、使用 Decision Table Testing 釐清需求與建立範例的步驟

從 Specification by Example（SBE）的觀點來使用 Decision Table Testing，重點不在於窮舉所有測試案例，而是協助團隊釐清需求邏輯、揭露模糊規則，進而挑選出具代表性且有意義的範例。

(1) 找出「決策點」與「判斷條件」

在 SBE 的脈絡中，第一步是從業務流程或使用情境中，找出會影響行為變化的「決策點」。這些條件不一定都來自系統邏輯，有時是政策規範、商業策略或隱含假設。

例如：在百貨折扣或高鐵團體票中，決策點可能是：
• 訂購數量是否超過門檻？
• 客戶身份是否為特定群體？
• 訂票是否為特定車次、平日或假日？
這些條件需由團隊共同釐清，才能確認有哪些「行為差異」存在。

(2) 梳理條件的組合，觀察是否會導出不同的行為

接著，針對條件組合列出對應的業務行為，形成 Decision Table。此時不是為了寫 test case，而是檢查：
• 條件邏輯是否清楚定義？
• 有沒有重複或衝突的條件？
• 有沒有「未定義」的灰色地帶？

在表中空白格子往往代表「需求未定義」，這是 SBE 中討論最重要的點。

(3) 挑出「行為不同」的組合作為代表性範例（非全部窮舉）

在 Specification by Example 中，我們只需要挑出足以代表每一種不同業務行為的情境，作為範例進行溝通與驗收條件確認。

例如：
• 一組可獲得全部優惠
• 一組只符合一種優惠
• 一組條件衝突但不應產生優惠
• 一組符合條件但遇上例外（如：人數達標但未指定車次）

這些範例就會成為 Product Owner、設計、測試與開發的共識起點。

(4) 轉換為 Gherkin 範例或可讀格式，用於協作與驗收

這些從 Decision Table 中整理出的情境，不是直接拿去做驗證，而是變成團隊一起討論與驗收的語言。

範例：
Scenario: 學校團體 15 人於平日搭指定車次
Given 訂購人數為 15 人，為國中學生
And 團體屬性為學校
And 日期為平日
And 搭乘車次為高鐵指定車次
When 計算票價
Then 應適用校外教學優惠：7 折

三、使用 Decision Table Testing 釐清需求時的注意事項

(1) 過度追求組合覆蓋，反而模糊了「核心行為」
a. 問題：
很多人把 Decision Table 當成 test matrix，試圖窮舉所有條件組合，但 SBE 的重點是「釐清業務規則」、「促進對話」，不是覆蓋率。這會讓討論偏離重點，大家開始關心邏輯完備性，而忘記討論業務真意。

b. 範例：
在高鐵校外教學優惠中，列出學歷、小學／高中／大專、是否指定車次、是否學校團體、平日／假日等，表格很快就爆炸成 30+ 種情境。結果團隊花一整場會議在「補表格」而非討論「誰能享優惠、誰不能」的真正商業邏輯。

c. 解法：
• 用 Decision Table 幫忙「揭露模糊點」，不是為了建立測試全集。
• 用紅筆標記「行為差異明顯」的欄位，從這些情境挑出 3~5 個關鍵範例。
• 對沒有差異的欄位（如只是學歷不同但優惠一樣），可以暫時合併類別。

(2) 忽略條件背後的「判斷邊界」
a. 問題：
Decision Table 只寫「是／否」，容易忽略業務判斷是如何成立的。例如條件「是否為學校團體」看起來簡單，但 SBE 要釐清：「學校名稱在哪裡填？誰來認證？可不可以是補習班？」

b. 範例：
條件列為「是否為學校團體」＝Y，結果大家都以為只要選「教育類機構」就好。但實際系統要填統一編號，並經人工審核，PO 沒明講，後來產出範例時才發現測試用戶被拒絕。

c. 解法：
• 每一個條件欄位背後都問一次：「怎麼知道？怎麼判定？」
• 在範例下方加註條件依據（如：「學校團體需提供教育部核可證明」）

(3) 行為對應不明確、無法拆解到驗收層級
a. 問題：
表格只寫「折扣 4%」這種粗略行為，但對於 SBE 來說，驗收是具體且可驗證的：「在 UI 上看到價格？」「票價有標註折扣訊息？」「是否產生某稅額變動？」

b. 範例：
「假日搭乘小學團體 → 不適用優惠」
表格上寫「無折扣」，但沒人討論 UI 是否需顯示「不適用校外教學優惠」，導致實作結果只是票價沒變，卻引來使用者困惑。

c. 解法：
• 將 Action 欄位拆成具體行為，如：
o 套用折扣 Y/N
o 顯示提示訊息 Y/N
o 是否允許訂票 Y/N
• 範例中呈現畫面輸出或流程限制，而不只是「內部邏輯正確」

(4) 忽略模糊條件的「分歧點」釐清
a. 問題：
表格會讓人誤以為條件已經明確，實際上有些條件在業務上是模糊的，需要透過 SBE 範例進一步釐清。例如：「指定車次」是怎麼指定的？是否限早上？可否跨區段？

b. 範例：
條件為「是否為指定車次」＝Y
大家誤以為是 PO 提供的表單中任一車次即可。後來 PO 才說只有早上 8:00–10:00 的區間車才適用。這段落在表格中完全看不出來。

c. 解法：
• 遇到條件模糊，反而要多挑一兩個範例呈現「邊界情境」
• 在表格中以備註標記「需進一步定義」的欄位

(5) 行為與條件比例不對稱，讓範例無法代表用例
a. 問題：
一張決策表可能包含 10 個條件，但實際業務只對其中 2–3 個條件有行為差異。此時產出的範例會變得冗長且沒有價值，因為大多條件無關結果。

b. 範例：
條件表中列出「乘客年齡」「搭乘地點」「學校是否為市立」…但實際影響折扣的只有「是否小學生」。
結果產出的範例都很複雜（年齡、地點、團體屬性…），但其實只需要針對「小學 vs 高中」這個行為差異點下手即可。

c. 解法：
• 決策表只是輔助工具，若某些條件無影響，應直接標註「不影響行為」
• 挑選範例時聚焦在「行為差異最大的組合」

(6) 決策表設計者視角太重，忽略使用者故事上下文
a. 問題：
許多 Decision Table 是 QA 或 BA 從技術角度寫出來的，但 SBE 是從「真實使用者行為」出發。若產出的範例無法講出使用者意圖與上下文，會失去溝通價值。

b. 範例：
Given 條件1為 Y
And 條件2為 N
Then 折扣為 2%
這樣的範例 QA 看得懂，PM 和設計師會說：「這什麼？」

c. 解法：
每個範例都應補上使用者角色與行為目的：
Scenario: 學校老師帶 12 名高中生於平日搭乘指定車次，申請校外教學優惠
Given 總人數為 12 人
And 乘客皆為高中生
And 選擇搭乘高鐵指定車次標準車廂
And 訂票日期為平日
When 詢問票價
Then 顯示票價為原價的七折

四、利用Decision Table Testing 釐清需求的範例

專案會議室，上午 10 點。白板上貼著一張張高鐵票價優惠的規則說明，PO 小惠正在快速走過規則重點。

「這次要實作的是學校團體預訂高鐵票的系統邏輯，包含三種優惠：一般團體、校外教學、25人以上團體折扣。」她說完轉身，大家一臉沉思。

小貞（測試工程師）開口：「這聽起來條件很多耶，是不是可以先用 Decision Table 來整理？」

PO 有點困惑：「Decision Table 是什麼？」

小貞笑著說：「就是把條件列出來，每個組合對應一個系統行為。我們可以先用這種方式，讓我們更容易抓出需要的範例，也確保沒遺漏邏輯。」

【第一輪：整理條件】
小貞走到白板前：「目前看起來，條件可能有——」

• 是否為學校團體
• 人數是否達 25 人
• 是否搭乘指定車次
• 是否搭標準車廂對號座
• 是否為假日
• 是否包含國小、國中、高中、大專學生

PM 阿明說：「你這樣寫，我開始搞混了耶。不是應該先分校外教學、25人團體、一般團體三類嗎？」
小貞搖搖頭：「這些優惠不是互斥的分類，而是根據不同條件疊加出來的行為，所以要先把條件攤開來。」

【第二輪：建立 Decision Table 草稿】
他們簡單整理出以下 Decision Table（僅列出 4 條件以簡化）：

【第三輪：爆炸的邏輯迷宮】
阿明搔搔頭：「欸，可是我們沒有區分小學生、國高中、大專的折扣耶……這會不會太細？」

小惠補充：「而且 25人優惠，是所有團體都適用？學校團體也可以享有？」

小貞反問：「所以，如果是學校團體，25人以上，又是指定車次，平日，那會同時有兩個優惠？怎麼算？」

PM 阿明眉頭一皺：「那這樣如果有國小 + 國中 + 大學生混在一起，折扣怎麼套用？」
現場沉默 10 秒。

【恍然大悟時刻】
小貞拍了一下筆記本：「我們剛才試著用一條邏輯走到底，結果卡住，是因為我們想一次定義所有行為。我們改個方式，用 decision table 的每一列來挑一組範例，反過來讓 PO 來確認『這樣的組合該怎麼算』，而不是問 PO：『規則怎麼寫』。」

大家眼睛一亮。
PO 小惠點頭：「對耶，這樣比較不會只靠我主觀講規則，我反而能用你們的範例，回頭檢查是不是我們真的要的行為。」

【第四輪：Specification by Example 實作】
他們從上面 decision table 中挑出三組 case 來請 PO 驗證：

範例 1：校外教學 + 25 人以上 + 平日
• 組成：5 小學生 + 10 國中生 + 10 高中生
• 指定車次、標準對號座
• 預期行為：校外教學可適用，小學生 4 折，其他人 7 折；若也適用 25 人優惠，就需釐清是否折上折或取其一。

範例 2：非學校團體 + 30 人 + 假日
• 指定車次、標準車廂
• 預期行為：應套用「25人以上團體假日 8 折」

範例 3：學校團體 + 20 人 + 非指定車次
• 預期行為：無法享校外教學優惠，只是一般團體

【結語】
這次討論不但讓需求釐清更有邏輯，還讓 PO 小惠第一次覺得：「原來範例不只是測試用的，它們幫我發現自己都沒想清楚的邏輯。」

從此，這個團隊每次釐清需求，都會把 decision table 當作範例蒐集器，而不是規則編輯器。他們學到一件事：
「不是只有寫規則才是定義需求，選擇範例，也是在定義需求。」